fix: complete generic function call defaults - #1535

Mainline #1535 builds `Self::Out` inside a generic trait from all of the
trait's parameters, so `impl<A, P: T<A>> T<A> for Wrap<P>` with
`fn f(_ a: A) -> Self::Out` now type-checks. Its fixture covers bare
associated names on concrete impls; these fixtures cover an impl that
stays generic over the trait's parameter.

The fe test fixture runs such an impl end to end. The type check fixture
keeps the diagnostic for a genuinely wrong return type, which names the
impl's actual `(P::Out, A)` instead of `Wrap<P>::Out`.

An explicit const argument such as the `3` in `Window<1> {}.take<3>()`
or `Window<1>::sum<3>()` must be evaluated against the parameter's type,
as a free function's is, so that constant evaluation of a method or
associated function can read its const parameter.

#1535 made this so: explicit call arguments of every function, methods
included, now go through the generic parameter schema's completion,
which evaluates them. Before #1535 such a constant panicked with
"instantiated constant template retains its value description". This
`fe test` fixture pins that behavior for methods and associated
functions.

An explicit const argument such as the `3` in `Window<1> {}.take<3>()`
or `Window<1>::sum<3>()` must be evaluated against the parameter's type,
as a free function's is, so that constant evaluation of a method or
associated function can read its const parameter.

#1535 made this so: explicit call arguments of every function, methods
included, now go through the generic parameter schema's completion,
which evaluates them. Before #1535 such a constant panicked with
"instantiated constant template retains its value description". This
`fe test` fixture pins that behavior for methods and associated
functions.

`caller_args` rebases a method body's inferred arguments onto the
method's own formals, so they compare with the caller's premises in one
basis. When that substitution failed it silently returned the arguments
unchanged (`.unwrap_or(args)`), while the equivalent failure one step
later, instantiating the requirement (`requirement_subst`), makes the
discharge fail. Comparing in two bases could miss a premise, or match one
it should not.

`caller_args` now returns `Result<_, SubstError>`, mainline's typed
substitution error, and `caller_premises` propagates it with `?`, the way
#1535's `MethodArgMapError` results are threaded through method argument
mapping. Discharge turns either failure into
`RequirementFailure::NotInstantiable`, as it does for `requirement_subst`.
No fixture reaches the failing substitution; no snapshot changes (log 39).

An explicit const argument such as the `3` in `Window<1> {}.take<3>()`
or `Window<1>::sum<3>()` must be evaluated against the parameter's type,
as a free function's is, so that constant evaluation of a method or
associated function can read its const parameter.

#1535 made this so: explicit call arguments of every function, methods
included, now go through the generic parameter schema's completion,
which evaluates them. Before #1535 such a constant panicked with
"instantiated constant template retains its value description". This
`fe test` fixture pins that behavior for methods and associated
functions.

`caller_args` rebases a method body's inferred arguments onto the
method's own formals, so they compare with the caller's premises in one
basis. When that substitution failed it silently returned the arguments
unchanged (`.unwrap_or(args)`), while the equivalent failure one step
later, instantiating the requirement (`requirement_subst`), makes the
discharge fail. Comparing in two bases could miss a premise, or match one
it should not.

`caller_args` now returns `Result<_, SubstError>`, mainline's typed
substitution error, and `caller_premises` propagates it with `?`, the way
#1535's `MethodArgMapError` results are threaded through method argument
mapping. Discharge turns either failure into
`RequirementFailure::NotInstantiable`, as it does for `requirement_subst`.
No fixture reaches the failing substitution; no snapshot changes (log 39).

An explicit const argument such as the `3` in `Window<1> {}.take<3>()`
or `Window<1>::sum<3>()` must be evaluated against the parameter's type,
as a free function's is, so that constant evaluation of a method or
associated function can read its const parameter.

#1535 made this so: explicit call arguments of every function, methods
included, now go through the generic parameter schema's completion,
which evaluates them. Before #1535 such a constant panicked with
"instantiated constant template retains its value description". This
`fe test` fixture pins that behavior for methods and associated
functions.

`caller_args` rebases a method body's inferred arguments onto the
method's own formals, so they compare with the caller's premises in one
basis. When that substitution failed it silently returned the arguments
unchanged (`.unwrap_or(args)`), while the equivalent failure one step
later, instantiating the requirement (`requirement_subst`), makes the
discharge fail. Comparing in two bases could miss a premise, or match one
it should not.

`caller_args` now returns `Result<_, SubstError>`, mainline's typed
substitution error, and `caller_premises` propagates it with `?`, the way
#1535's `MethodArgMapError` results are threaded through method argument
mapping. Discharge turns either failure into
`RequirementFailure::NotInstantiable`, as it does for `requirement_subst`.
No fixture reaches the failing substitution; no snapshot changes (log 39).

`fn f(a: Holder<{ id<5>() }>::Out, b: Holder<{ id<5>() }>::Out)` made
the compiler panic with a query cycle. Building f's parameter list
lowers its parameter types. Resolving `::Out` type-checks the const
block, which evaluates the `5` in `id<5>`. That evaluation built its
capture environment up front, which asks for f's parameter list again.

Since #1535 the capture environment is built at the start of
evaluate_const_ty, even for a literal or arithmetic that never reads
it. Build it on first use instead. The value is the same wherever it
is used, so results do not change; only the needless dependency goes
away. A const block passed as a generic argument inside such a
parameter type (`id<{ id<5>() }>`) still needs the environment and
still cycles; that is left for a separate change.

`fn f(a: Holder<{ id<5>() }>::Out, b: Holder<{ id<5>() }>::Out)` made
the compiler panic with a query cycle. Building f's parameter list
lowers its parameter types. Resolving `::Out` type-checks the const
block, which evaluates the `5` in `id<5>`. That evaluation built its
capture environment up front, which asks for f's parameter list again.

Since #1535 the capture environment is built at the start of
evaluate_const_ty, even for a literal or arithmetic that never reads
it. Build it on first use instead. The value is the same wherever it
is used, so results do not change; only the needless dependency goes
away. A const block passed as a generic argument inside such a
parameter type (`id<{ id<5>() }>`) still needs the environment and
still cycles; that is left for a separate change.